Author: Robert Jones, email: robert.jones0@talk21.com
References:
1. Committee Draft 1.5 for the proposed revision of ISO 1989:1985, COBOL standard. (I started on this version and got as far as the beginning of intrinsic functions, then checked and converted my comments for version 1.6, when it appeared.)
2. Committee Draft 1.6 for the proposed revision of ISO 1989:1985, COBOL standard.
3. 99-0217, Dates, Times and Durations, written by myself early in 1999 and subject to much needed continuing improvement since.
Comments:
1 General re bookmarking
The bookmarking in the Adobe Acrobat document does not have a separate primary entry for Intrinsic Functions, it is currently under the "WRITE" statement. There are other similar cases, for example, for the "Data Division" and the "Procedure Division". It seems desirable to me for each primary subdivision to have its own primary level bookmark. It must be said that there isn't a problem if one uses the document's own table of contents instead of the bookmarking facility, but this involves returning to the front of the document each time it is used.
2 General re transfers of control in procedure division statements with conditional phrases
It might be preferable to specify some common rules in "14.7.2 Explicit and implicit transfers of control" rather than repeat for each statement very similar text in AT END, INVALID KEY, and other conditional phrases (e.g. those in ADD, CALL, IF and EVALUATE), some of which already make reference to common text in 14.7.9.2 exception conditions. There could also be an argument for having a entry for the AT END condition in a similar style to that of "9.1.12 Invalid key condition".
3 General re object orientation facility
I find this very complex and hard to comprehend and still haven't understood it properly. I suspect that many other programmers would find it hard going too. I would be very worried about the quality of the resultant programs, which I think could be extremely difficult to maintain. I suspect that implementations without this feature would be simpler and potentially more reliable as a consequence, as would the resultant programs, though that could be affected by the quality of the designers and other personnel wishing to work on them. Many of the better designers may be attracted by the challenge and extra bells and whistles of object orientation. I think it would be better as an optional feature, though at this late stage, I would imagine that that would be impractical.
I admit that I have never used object oriented facilities, except in very small sample PC programs. I realise that a standard document is not intended as a beginners guide, though I have done some reading on the subject and seen examples in other programming languages. However, while Annex C.18 for the concepts certainly helps, I don't think it really goes far enough.
4 General re reference formats
While I like the introduction of free-format lines as a concept, many programs in substantial systems have used the sequence number area of fixed-format lines for other purposes such as amendment identification. I think it would be desirable to permit such uses to be continued across to free-format lines. It probably wouldn't be too difficult to do this with some minor modifications to the draft, most notably by including the facility to specify the start column for each line in the SOURCE FORMAT directive. The default start column would be the first column. A suitable optional phrase for the SOURCE FORMAT directive might be "STARTING AT COLUMN n", which optionally could be allowed to be abbreviated to "STARTING n".
5 Definitions, 4.20, Alternate Record Key, page 9
Add the sentence "When specifically allowed, there may be duplicate records with the same alternate record key.".
6 Definitions, 4.32, Bit Position, page 9
either the title or its description is inappropriate. For the title a more appropriate description would be "The location in physical storage where a single bit is stored, or the presentation space where a single bit is printed or displayed." For the description a more appropriate title would be "Bit Position Size".
Maybe a better "catch-all" would be "Variously, the location or amount of physical storage where a single bit is stored, etc". This would cover both types of use within the remainder of the document. (The words position and location are synonyms.)
7 Definitions, 4.41, Boolean Position, page 10
similar comments apply as to Bit Position.
8 Definitions, 4.54, Character Position, page 10
similar comments apply as to Bit Position.
9 Definitions, 4.86, Complex Condition, page 12
this would seem to describe any condition, it could be better described as a condition that consists of two or more simple conditions. It might also be considered to apply to any condition containing the "NOT" operator.
10 Definitions, 4.103, Contiguous Items, page 13
I would prefer "Items within the same record description that are adjacent in storage."
11 Definitions, 4.116, Currency sign, page 14
For completeness, it should also be stated that this definition can be modified by using the CURRENCY SIGN clause of the SPECIAL-NAMES paragraph.
12 Definitions, 4.127, Data-Pointer Data Item, page 14
Replace "address of a data item" by "address of another data item".
13 Definitions, 4.128, Debugging Indicator, page 14
This only describes the case for the free-form source line.
Perhaps the existing text could be rephrased and expanded as follows:
"The Debugging indicator is used to identify a source line as a debugging
line. When specified as the first non-space characters of a free-form source
line, the debugging indicator is the three contiguous COBOL characters
'>>D'. In a fixed-form source line, the debugging indicator is the COBOL
character 'D' in the indicator area.'.
14 Definitions, 4.129, Debugging Line, page 14
Replace "OBJECT-COMPUTER" by "SOURCE-COMPUTER".
15 Definitions, 4.132, Declaratives, page 14
I think that it would be clearer to amend the first clause to read "A set of one or more special purpose sections in the procedure division,".
16 Definitions, 4.140, Digit Position, page 15
similar comments apply as to Bit Position. However, having done a search of the CD1.5 draft, I found that all uses of the term "digit position" are conventional, rather than as defined in the Definitions.
17 Definitions, 4.153, Enter Key, page 15
I think it would be better stated as: "A key on the keyboard of a character addressable terminal that is pressed to signal that the input of the screen item or the screen record is complete and that the content is to be sent for processing.".
18 Definitions, 4.201, Function, page 18
While a function certainly behaves in this manner, I think the description would be better expressed as follows: "A procedural entity that behaves as a temporary data item whose value is determined at the time an intrinsic or user-defined function is referenced during the execution of a statement."
19 Definitions, 4.202, Function-identifier, page 18
Replace "user-defined-name" by "user-defined-function-name".
20 Definitions, 4.245, Intrinsic-function-name, page 20
While true, I don't think it really provides adequate information. At the least, I think that the final word "function" should be replaced by "specific function".
21 Definitions, 4.276, Merge File, page 21
"A collection of records to be merged by a MERGE statement." - original
I would prefer "One of the input files to a MERGE statement." Alternatively, "The logical collection of records sequentially released to the output procedure of a MERGE statement, after having been collated according to the specification of that MERGE statement." This latter form would be more accurately described as a merged file.
22 Definitions, 4.282, Method, page 21
"Procedural code that is declared in the procedure division of a method definition." - original
I think that a better title for this description would be "method code".
I think a better description for "method" would be "A process defined by a method definition within or inherited by a class definition as one of the operations that may be specified as actions upon objects of that class."
23 Definitions, 4.293, National Character Position, page 22
similar comments apply as to Bit Position. However, looking up the places in which it is used seems to indicate that it is a reasonable description.
24 Definitions, 4.307, Noncontiguous Item, page 23
Logically, two items separated by another item within the same record description could also be described as noncontiguous. The document contains no instances of this phrase, nor of "non-contiguous item", but "noncontiguous" is used with the term data item. This would suggest that the title should be revised to "noncontiguous data item".
8.5.1.2.1 Level numbers, page 114
13.11 77-level data description entry, page 249
in this description the use of the term "item" might be better replaced by "data item".
25 Definitions, 4.321, Obsolete Element, page 23
"Obsolescent Element" would be a more accurate title for the description.
26 Definitions, 4.347, Prime Record Key, page 25
"A key whose contents uniquely identify a record within an indexed file." - original
Unique alternate record keys would also qualify for this description.
I think the phrase "and which forms part of the primary index for that file" should be appended.
Alternatively, replace "A key" by "A key defined using the RECORD KEY phrase of the file-control entry and".
27 Definitions, 4.363, Qualifier, page 26
Item 1.
"A data name or a name associated with a level indicator that is used in a reference either together with a data name of an item that is subordinate to the qualifier or together with a condition-name." - original
I think that this would be better for rephrasing as follows: "A data name or a name associated with a level indicator that is used in a reference together with a data name or a condition-name of an item that is subordinate to the qualifier.".
28 Definitions, 4.367, Radix, page 26
I think that either there should be two uses of the term "place" or two of the term "position".
29 Definitions, 4.370, Record;logical record, page 26
I think that the title should just be "record", or possibly "record;logical".
30 Definitions, 4.372, Record Description; Record Description Entry, page 26
I think that the title should just be "record description".
31 Definitions, 4.373, Record Description Entry; Record Description, page 26
I think that the title should just be "record description entry".
32 Definitions, 4.379, Record Number, page 26
Add "or relative" to the end of the sentence, or make a reference to "relative record number" to emphasize the distinction. Maybe a better title would be "sequential record number", in which case it would be necessary to recheck all uses of the term "record number".
33 Definitions, 4.425, Sequential Organization, page 29
"The permanent logical file structure in which a record is identified by a predecessor-successor relationship established when a record is placed into the file." - original
I think that this description would be more appropriate for a linked list. While implementors would be free to implement such a structure for a sequentially organized file, from the point of view of the COBOL programmer it would be irrelevant. I would prefer one of the following descriptions.
"The permanent logical file structure in which a record is identified solely by its sequential position within that file."
"The permanent logical file structure in which records are logically and usually physically placed in a storage medium so that they are positioned in the order of the sequence in which they are written and can only be retrieved in that sequence or its exact reverse. New records can only be added after the logical last record of the file."
or, to allow for linked lists, maybe:
"The permanent logical file structure in which the records are ordered by the predecessor-successor relationship established when the records were placed in the file. The constituent records can only be retrieved in the order in which they were written or its exact reverse."
If the definition is meant to cover situations where linked lists are included, then one might point out that it is possible to insert records within a linked list, but that such activity is not covered by the COBOL definition of sequential organization, since in COBOL records can only be added to the end of a file that is sequentially organized.
34 Definitions, 4.431, Simple Condition, page 29
I think that "(simple condition)" should be deleted from the end of the list.
35 Definitions, 4.433, Sort File, page 29
similar comments apply as to Merge File.
36 Definitions, 4.452, Subprogram; Called Program, page 30
";called program" should be deleted from the title.
37 Description techniques, 5.1.3, Operands, page 32
Third line, I think the term integer-literal would be more self-explanatory, on the other hand it is arguable that integer is briefer and the context usually makes the meaning obvious.
38 Description techniques, 5.x numeric position control variables and counters, page 35
In the STRING statement (syntax rule 6) and the UNSTRING statement (syntax rule 5), the use of the "P" picture symbol in the definition of integer data items used as numeric position control variables and counters is specifically disallowed. Such a rule would be applicable to several other statements and entries in the environment, data and procedure divisions.
There is a case for making a separate statement to this effect rather than repeating it in the rules for each feature so affected.
I have done a partial search for cases where the term integer is used in the rules for an operand, where such a rule would be appropriate. So far I have found: OCCURS, ACCEPT, DISPLAY, INSPECT, PERFORM, SET and WRITE.
8.4.1.2 Subscript and 8.4.2.3 Reference-modifier though analogous are somewhat special cases about which I have to think some more, they use the term arithmetic expresssion, which must evaluate to a positive non-zero integer, to define the operands. Perhaps in these cases it might be desirable to specify that where the arithmetic expression consists of a single operand that is a data item, that that data item shall be defined without decimal places or a "P" symbol in its picture string.
While it is arguable that some numeric position control variables could have "P" symbols in their picture string definitions, e.g. in WRITE and DISPLAY, where multiples of ten might in some circumstances be acceptable, I think that it is generally undesirable and that these two examples do not justify allowing such use of the "P" symbol.
Such a rule might best be positioned in "5, Description techniques", perhaps as a subordinate addition to 5.4 Integers or as a separate title such as "5.x Integers used as numeric position control variables and counters".
Perhaps the rule should be "Where it is specified that an operand must be an integer and that operand may be a data item, then the picture string for that data item shall not contain the "P" symbol.".
Some exceptions may be necessary for intrinsic functions, I have yet to look at them.
39 6.3 Logical Conversion, page 40
Fourth paragraph, commencing "The rules given below ...". I think that the second sentence should commence with the phrase "For the purposes of these rules".
Tenth paragraph, commencing "The next fixed-form line is then examined ...". I think that the second sentence should be rephrased as follows: "If it is a blank line or the indicator area of the fixed-form line contains an asterisk or slash, the line is ignored and the process of examining the next fixed-form line is repeated."
40 COPY Statement, 7.1.2.3, General Rules, page 43
Rule 3
"If the SUPPRESS phrase is specified, library text incorporated as a result of COPY statement processing is not listed. If a listing is being produced, the COPY statement itself is listed." - original
I would have thought that this would be better expressed as follows:
"Subject to the use of LISTING compiler directives, if the SUPPRESS phrase is not specified, first the COPY statement itself is listed, then library text incorporated as a result of COPY statement processing is listed. If the SUPPRESS phrase is specified, then only the COPY statement is listed. Incorporated library text may itself contain LISTING compiler directives."
If it is not desired to mention the use of the LISTING compiler directive in the general rules for the COPY statement, then the following text could be used instead.
"If the SUPPRESS phrase is not specified, first the COPY statement itself is listed, then library text incorporated as a result of COPY statement processing is listed. If the SUPPRESS phrase is specified, then only the COPY statement is listed."
41 Conditional Compilation, 7.2.5 Compile-Time Arithmetic Expressions, page 50
Rule 5 from the CD1.5 draft, "A compile-time arithmetic expression shall not result in a size error condition.". - original. (This has now been replaced by Syntax rule 1c in the reorganisation of 7.2.5 in the CD1.6 draft.)
I still think that this is excessively hopeful, bearing in mind the ability to specify conditional variables using the DEFINE directive. Perhaps it should be restated, in whole or in part, as follows:
"Any syntax errors, size errors, format incompatibilities or invalid references arising during the process of evaluating a compile-time arithmetic expression shall be detected by the compiler and cause a compiler error message to be produced, the nature and details of which are implementor defined. The use of run-time exception handling facilities is not available to compile-time activity.".
Alternatively and less satisfactory, perhaps:
"Where the processing of compile-time arithmetic expression causes a size error condition, the result is undefined and unpredictable. The use of run-time exception handling facilities is not available to compile-time activity.".
or
"Where the processing of compile-time arithmetic expression causes a size error condition, the result is an undefined and unpredictable valid numeric value. The use of run-time exception handling facilities is not available to compile-time activity.".
Maybe a more general comment about handling errors when processing compiler directives would be preferable.
Possible addition to "7.2.3 General Rules" for compiler directives, alternatively and without the paragraph number, it could be placed after the single paragraph in "7 Compiler Directing Facility".
"5) Any syntax errors, operand format incompatibilities, invalid operand references, placement errors or size errors arising during the process of applying compiler directives shall be detected by the compiler and cause appropriate compiler error messages to be produced, the nature and details of which are implementor defined. The use of run-time exception handling facilities is not available to compile-time activity.".
Obviously there could also be logic errors in that a compiler directive as written may be syntactically correct, function according to the rules of the compiler and even produce valid source text that is successfully compiled, but still not do what the programmer had intended. However, this can apply to any COBOL statement and construct and a compiler can not be expected to detect such cases.
I have since seen 99-0287 by Don Nelson and would generally agree with what he says, with the proviso that unless division by compile-time variables is banned, then size errors will occur whenever they have the value of zero, as well as when dividend and divisor are otherwise unsuitably matched. Also, multiplication by one or more compile-time variables could give rise to a result that has excessive magnitude. I prefer my own approaches to the handling of errors as explained above.
42 8.1.1 Computer's Coded Character Set, pages 66 and 67
At the bottom of page 66 and the beginning of page 67, there are statements about numbers of bytes in character sets. I think the intention is to specify consistency in the representation of characters, such that the number of bytes in the memory of a computer needed to represent a character is the same for each character within an alphabet. I think the problem is just a matter of phraseology.
I think that the last sentence on page 66 should commence as follows: "The COBOL specification is independent of the encoding used to represent a computer's coded character set, except that, at both compile time and run time:".
I think that the last item (number 1) on page 66 would be better rephrased as "each character in the alphanumeric coded character set is to be represented by the same number of bytes in the memory of the computer as each other alphanumeric character;".
I think that the first item (number 2) on page 67 would be better rephrased as "each character in the national coded character set is to be represented by the same number of bytes in the memory of the computer as each other national character; and".
I think that the second item (number 3) on page 67 "the number of bytes in the representation of the national coded character set are to be equal to or greater than the number of bytes in the representation of the alphanumeric coded character set." would be better rephrased as "the number of bytes used to represent each character of the national coded character set is to be equal to or greater than the number of bytes used to represent each character of the alphanumeric coded character set.".
I am not entirely sure about what is permitted in a composite character set, perhaps it would be desirable to state that where characters from the alphanumeric coded character set are mixed with a national coded character set to form a composite coded character set, then each character within that composite is to be represented by the same number of bytes as each other character. If this isn't done, then for example, I can't see how the intrinsic LENGTH function can work.
43 Uniqueness of Reference, 8.4.1.2.2 Syntax Rules, item 6, page 94
I think this should be rephrased as follows:
"The subscript ALL may be used only when the subscripted identifier is used as a function argument or to identify the table in the table format of the SORT statement." That is substantially to use "or" instead of "and".
44 Uniqueness of Reference, 8.4.1.2.3 General Rules, item 1c, page 95
first sentence, insert "optionally" in front of "modified".
45 Arithmetic Expressions, 8.8.1.1, Native and Standard Arithmetic, item 6, page 125
The word "of" seems superfluous.
46 Arithmetic Expressions, 8.8.1.3.1.1, Precision and Allowable Magnitude, page 125
I think that it is typographically undesirable to allow a superscript to be separated from the item for which it is a superscript. It is even more undesirable to separate a superscript or other value from its sign as is done on lines one and two of the paragraph.
While this has now been fixed in this particular case in CD1.6, I think it is worth bearing in mind as a general consideration.
47 Concatenation Expressions, 8.8.3, Syntax Rules, items 2,3 & 4, page 129
I have yet to find why it is necessary to limit the length of the result to 160 alphanumeric, boolean or national characters. I can imagine that there is a good reason, but haven't remembered, found it or thought of it yet.
48 Conditional Expressions, 8.8.4.1.1.4, Comparison of a numeric integer operand with an operand of class alphanumeric or national, page 132
Consider the way in which numbers are to be handled when the number is stored in a numeric data item of usage display or national with the picture symbol "S". The USAGE clause effectively states that though the position and way in which a sign is represented without the SIGN IS SEPARATE clause is implementor defined, nevertheless all the characters used for the representation of a sign in combination with digits 0-9 in one or more specific character positions of a such a data item should be included in the the repertoires of both alphanumeric and national characters.
review with respect to 8.1 Character sets, 8.5.1.5 Algebraic signs, 8.8.4.1.3 Class Condition, also 13.16.39 PICTURE, 13.16.51 SIGN and 13.16.59 USAGE (general rules 7 and 8) clauses and 14.10.24 MOVE statement, especially general rule 4a.
I tend to think that 8.1 Character sets should include an explanation to this effect, perhaps as a note. Also, perhaps, that 8.8.4.1.1.4 should contain a note to the effect that the sign if present is ignored. I know that general rule 4a of the MOVE statement says this, but it would bear emphasis.
49 Input/output and objects, 9.1.2, File connector, page 149
Second paragraph, third sentence, replace "When a CLOSE statement references the associated file-name" by "When a CLOSE statement that references the associated file-name is executed".
50 Page numbering for page 149 is missing, as are several others
51 Input/output and objects, 9.1.6.1, Sequential organization, page 150
I think that "When this technique is used" can be misinterpreted to mean "When a sequential file is held on mass storage", I did so myself. Consequently, I think that it would best be replaced by "When updating in place is used".
52 Input/output and objects, 9.1.7.1, Sequential access mode, page 151
Third paragraph, fourth line, replace "form" by "from".
53 Input/output and objects, 9.1.11, I-O Status, page 152
Second paragraph, second and third sentences, after "9.1.11.1, Successful completion," insert the word "occurs". An alternative and perhaps neater approach would be to replace the word "If" at the beginning of both sentences by the word "For".
54 Input/output and objects, 9.1.11.8, File sharing conflict condition with unsuccessful completion, page 156
Rule 1e for I-O Status 61 duplicates the function of I-O Status 41.
Also affects D.1, Substantive changes potentially affecting existing programs, item 2, I-O Status "61".
55 Screens, 9.2, page 160
"Functionality" is misspelt.
56 COBOL Compilation Group, 10.1.1.1, General format, page 170
I think that the preliminary list should also include "factory", "object" and "method-definition".
57 COBOL Compilation Group, 10.2.1, General format, page 174
I think that the list of end-markers should be in the same order as the definitions in 10.1.
58 Identification division, 11.1, General format, page 176
I think that it is desirable that the itemised list of paragraphs should be in the same order as their subsequent definitions, specifically "function-id-paragraph" should follow "interface-id-paragraph".
59 Environment division, 12.2.4, Source-computer paragraph, page 191
The heading "12.2.4 SOURCE-COMPUTER paragraph" should be in bold typeface.
60 Environment division, 12.2.5, Object-computer paragraph, page 192
The heading "12.2.5 OBJECT-COMPUTER paragraph" should be in bold typeface.
61 Environment division, 12.2.6, Special-names paragraph, page 195
The heading "12.2.6 SPECIAL-NAMES paragraph" should be in bold typeface.
Also, I think that the preliminary list should be in the same sequence as that of the general format. It may also be desirable for the preliminary list to be more comprehensive.
62 Special names, 12.2.6.2, Syntax rule 25, page 199
The reference to a "T format literal" in the final note, might be better expressed as to a "mixed text alphanumeric literal". Alternately, perhaps "T format literal" should be included in the definitions.
63 Repository paragraph, 12.2.7, General format, page 202
I think that the layout of the detail subject to the "where function-specifier is:" could be improved by indenting the "Format 1" and "Format 2" headings and further indenting the corresponding "FUNCTION" statements, which ideally would have the same level of indentation.
The general consistency of indentation of the whole of "12.2.7.1, General format" could be improved.
64 Repository paragraph, 12.2.7.3, General rules, page 207
Rule 5, last sentence. Does this also apply to the resolution of other compiler directives, in particular, EVALUATE and IF?
Same applies to rule 8.
65 Input-output section, 12.3, pages 207-
Many of the headings at the third and fourth level would be improved by using a bold font, e.g. 12.3.4, File control entry and 12.3.5, I-O-CONTROL paragraph.
66 Data Division, 13, pages 234-
Many of the headings at the third and fourth level would be improved by using a bold font, e.g. 13.3.4, File description entry and 13.16.61, VARYING clause.
67 Constant entry, 13.9, General format, page 246
It would provide more flexibility if one were able to specify whether a constant entry defined using arithmetic-expression-1 is an integer or an item whose description matches that of a standard-intermediate data item using standard arithmetic. This might be done by optionally preceding the arithmetic expression by the words INTEGER or STANDARD-INTERMEDIATE, where INTEGER would be the default. The STANDARD-INTERMEDIATE phrase could be used whether or not standard arithmetic was in effect for the compilation unit, as a special case. As currently planned for this standard, all compilers would in any case have to support standard arithmetic as an option.
Corresponding changes would be needed to syntax rule 2 and general rule 2. I have checked for instances of constant-name and found no problems elsewhere. The PICTURE clause deals with the situation by stating that an integer may be specified as a constant-name. Overall, I wouldn't expect any problem, since it is already the case that a constant-name specified using a literal need not be an integer.
Such a feature could provide more efficient evaluation of certain expressions, since the operation need only be done once.
I know that this is probably more of a change than the committee planned to consider at this late stage, but it would be very minor in its impact upon the text and organisation of the standard. On the other hand one could reasonably argue that the benefit of such a revision is marginal and it would best be deferred to the next standard or not bothered with at all.
68 Data description entry, 13.14.2, Syntax rules, page 256
Rule 15, to prevent the based clause being allowable in other circumstances such as local-storage with any level number, remove "whose level number is 1 or 77" and add a new sentence "The level number of such data description entries must be 1 or 77.".
69 Screen description entry, 13.15, Format 2 (elementary), page 259
Penultimate line, separate "described" from "in".
70 Screen description entry, 13.15.3, General rules, page 261
Rule 1, I don't think this should apply to the OCCURS clause. But it would be consistent with the way the FROM clause is specified, which itself is open to question. The OCCURS clause specification indicates that two levels of OCCURS are allowed.
71 Based clause, 13.16.5, page 267
A based data item should be at level 01 or 77, a reference to 13.14 syntax rule 15, which states this, would be helpful.
I don't think that it is practical to use it with a dynamic table, see OCCURS clause, format 3. I have yet to find where else such restrictions may be specified already or how and why they should not apply. Also review the ALLOCATE, FREE and SET statements.
Dynamic tables have been removed in CD1.6.
ref. 13.14, Data description entry, syntax rules 13, 14, 15 & 19.
72 Column clause, 13.16.14.2, Syntax rules, page 277
Rule 6c, not only the largest need cause an overflow. However, general rules 4 and 18 catch the problem. So probably no action is required.
Similar feature with 13.16.34, LINE clause.
73 Error clause, 13.16.21, General rule 6, page 287
I think that the beginning of the paragraph would be better expressed as "If neither an ERROR nor a NO ERROR phrase ...".
74 Format clause, 13.16.24.3, General rules, page 292
Rules 4 and 6, between the two it seems that data items with class numeric and usage display or national are excluded from the conversion. Maybe what should be done is to add "- class numeric with usage display" and "- class numeric with usage national" to the list in item 4.
75 From clause, 13.16.25.2, Syntax rules, page 294
Rule 3. "If the subject of this entry is subject to an OCCURS clause, identifier-1 shall be specified without the subscripting normally required." - original
I think that this would be better stated as:
"If the subject of this entry is subject to an OCCURS clause, identifier-1 shall also be subject to an OCCURS clause with the same number of entries and identifier-1 shall be specified without the subscripting normally required."
cf. ERROR Clause, 13.16.21.2, Syntax rule 5. It may be desirable to follow this definition more closely, if it is decided that a screen description entry may have a hierarchy of OCCURS clauses. The OCCURS clause, 13.16.37.2, Syntax rule 22 specifies that a hierarchy of two levels of OCCURS clauses may be specified in a screen description. Syntax rule 23 goes on to state appropriate rules for the FROM, TO and USING clauses. Perhaps an appropriate reference to the OCCURS clause should be made in the descriptions of the FROM, TO and USING clause.
76 Invalid clause, 13.16.30.2, page 299
What is is the point of an INVALID clause without an associated WHEN phrase.
77 Picture clause, 13.16.39, introductory text, page 319
Replace the comma after requirements by the word "and".
78 Picture clause, 13.16.39.5, Precedence rules, page 331
Table 9, First Symbol, Fixed Insertion Symbols, last two items entitled "cs" with the "c" and "s" vertically arranged. It would be easier to comprehend the symbol "cs" when it is horizontally arranged, provided there is room on the line.
Table 9, for the column with the symbol "E", I think that the first +/- combination row intersection should be blank.
Table 9, for the intersection with the second "cs" column and the second "+/-" row as fixed insertion symbols, I think this should be allowed. Conversely, I think that the intersection with the second "cs" row and the second "+/-" column should be disallowed.
Table 9, for the intersection with the first "cs" column in the fixed insertion symbols and the first "+/-" row in the floating insertion symbols, I don't know whether this should be allowed or not. To allow it would conflict with syntax rule 21, but on the other hand it would not be unreasonable. I think this should be reviewed.
79 Same as clause, 13.16.48.3, General rules, page 348
Rule 2c, this could include a statement to the effect that in the process of renumbering level numbers, level numbers 66, 77 and 88 will not be used, except for level 88 numbers copied from the subordinate definitions within a group item specified by data-name-1.
80 Source clause, 13.16.52.2, Syntax rules, page 353
Rule 3, this makes no sense, because data-name-1 is not specified in the general format. It looks as though this rule has been inadvertently copied from the SUM clause.
81 Sum clause, 13.16.52.2, Syntax rules, page 354
Generally, I think it would be desirable to explain the meaning of the distinction between data-name-1 and identifier-1 and how they would be distinguished in practical use.
82 Type Clause, 13.16.56.2 Syntax Rules, page 361
Rules 2 and 10 overlap, rule 2 could be omitted without loss of sense.
Rule 3 could add "directly or indirectly" before the word "references".
Is there a way of preventing level numbers 66, 77 and 88 being assigned during the process of renumbering level numbers arising from use of a TYPE clause, or can it be taken for granted that they will be automatically avoided during compilation, could such level numbers exceed 100, especially by use of more than one TYPE clause, if it is allowed?? How are circular references avoided. Also see my comments on the same as clause.
83 Typedef clause, 13.16.57.3, General rules, page 366
in rule 4, reference is made to "8.6 Types", this should instead refer to "8.5.3 Types", this rule could also refer to "13.16.56 TYPE Clause".
It seems to me that it would be undesirable for a TYPEDEF clause to be specified at any level other than 01 or 77. Perhaps such a restriction should be specified as syntax rule 2.
84 Value clause, 13.16.61.2, Syntax rules, page 374
I think a note would be beneficial, to the effect that the implied zeroes before or after the decimal point for a picture clause with one or more "P" symbols should be specified explicitly within the numeric literal used in the value clause.
85 Value clause, 13.16.61.2, Syntax rules, page 375
Rule 4, it would be logical for the last sentence of rule 3 to be copied and suitably adapted as the last sentence of rule 4.
86 Value clause, 13.16.61.2, Syntax rules, page 375
Rule 5, I think that it is desirable to specify that literals in value clauses for numeric-edited data items should be specified as alphanumeric literals delimited by the appropriate separators.
87 Varying clause, 13.16.62.2, Syntax rules, page 380
I think that rule 2 would be better expressed as follows:
"Data-name-1 shall not have been separately defined within the source element or as a global data item within a containing source element. Its specification within a VARYING clause causes a temporary data item that is a numeric integer to be established solely for use within that clause and other clauses of the subject of the entry and any subordinate entries. References to it are only valid within the clauses of the entry in which it is specified or within other subordinate entries.
The name of the temporary data item referenced by data-name-1 may be reused in a VARYING clause of an entry not subordinate to the subject of the current entry, but such a reuse will refer to a completely independent temporary data item."
88 Varying clause, 13.16.62.3, General rules, page 380
I think that rule 1 would be better expressed as follows:
"The temporary integer numeric data item referenced by data-name-1 shall be large enough to contain the largest possible value that could be used, to be calculated according to the specification of the associated VARYING and OCCURS clauses."
I realise that normally the general rules should contain detail such as the use of temporary data items, but I think that the explanation would be clearer for this rearrangement.
It is possible for a VARYING clause to be specified by a programmer in such a way as to make it impractical to have a temporary data item that could hold the maximum possible value. In such cases an appropriate exception condition should be raised, which then raises the question of how data-name-1 would be identified to an exception procedure. I think that such an exception would also contradict the concept that the VALIDATE statement doesn't fail except in strictly limited circumstances, see 14.10.46.3, general rule 5e. Potential exception handling would probably be easier if data-name-1 could not be reused by independent varying clauses.
89 Procedure division, 14.2, Syntax rules, page 382
Rule 10, this conflicts with general rule 4, I think it needs rephrasing or expanding. Also see a similar comment for the call statement.
90 Procedure division, 14.3, General rules, page 384
Rule 12, "table11" should be split into "table" and "11" with an intervening space.
91 Arithmetic statements, 14.8.4, page 401
The final note for item 3 could mention that a size error condition can also be raised in native arithmetic, if the implementor so defines, see 14.8.2 ON SIZE ERROR phrase and size error condition, first item 4 on page 401. Perhaps instead there should be an appropriate note at the end of item 2.
92 Retry phrase, 14.8.6.2, General rules, page 404
Rule 4, the final two sentences should be repeated within 4a, just before the final word "otherwise".
93 Conformance for parameters and returning items, 14.9.1.1, Group items, page 404
Penultimate para, when the calling program is separately compiled from the called program, how can it be checked that both argument and parameter are strongly typed? Maybe it is intended to be a requirement that the separate runtime modules both contain details of strongly typed items used as arguments and parameters for cross checking at execution time.
94 Accept statement, 14.10.1.2, Syntax rules, page 409
Rule 2, rather than also excluding such classes as pointers and objects, it might be better to rephrase this to specify which data classes or categories are allowed, for example:
"Identifier-2 shall reference an alphanumeric, national, numeric or numeric-edited data item that is large enough to receive the sending field without truncation."
95 Accept statement, 14.10.1.3, General rules, page 411
Rule 8, this seems unnecessarily split between two pages.
Rule 8, the characters " 31." should be added to the very end.
Rule 11, the number of seconds past the minute should range from 00 to 60, to allow for leap seconds.
96 Add statement, 14.10.2.2, Syntax rules, pages 413-4
Rule 1a, replace existing text by "In format 1, by separately pairing the common set of all instances of identifier-1 and literal-1 with each instance of identifer-2.".
97 Add statement, 14.10.2.3, General rules, page 415
Rule 5, it might be desirable to add "14.6.5 Explicit and implicit scope terminators" to the list. On the other hand it is arguable that to do this here would imply the need for such a phrase for every statement that can have a scope delimiter and that this would just add unnecessary bulk to the standard. Most people who would be interested in using the standard could be expected to understand the concept of scope delimiters, which are in any case explained separately.
98 Allocate statement, 14.10.3.3, General rules, page 416-7
Rule 4b, replace "the based" by "the address of the based", cf rule 5b.
Rule 9, the final sentence should be deleted, it looks like a leftover from a previous version.
99 Call statement, 14.10.4.2, Syntax rules, page 419
Rule 4, for the purposes of presentation, I think it would be better if this were made rule 1 and existing rules 1, 2 and 3 renumbered accordingly. Unless there is good reason to the contrary, such as description in the order of the phrases in a statement or of common features and aspects, I think that rules for identifiers, literals, etc should be in the order in which the latter are numbered.
Rules 7 and 8, these could be reversed in order for the same reason.
Rule 7, the same could be said for usage national when each character in the national character set is represented by other than a whole number of bytes. The standard doesn't seem to prohibit such a representation for national character sets.
Rule 10, this conflicts with general rule 6. Also see a similar comment for the procedure division header.
Rule 22, I think that this should apply to all formats.
100 Display statement, 14.10.10.3, General rules, page 434
Rule 11, this seems more like a syntax rule.
101 Divide statement, 14.10.11.2, Syntax rules, page 437
Rule 3, identifier-3 should not be included in the determination of the composite of operands, this would then be consistent with the add statement, see 14.10.2.2 syntax rule 1b.
This would mean revising the rule by deleting all words following "using" and replacing them by "identifier-1 and identifier-2".
Reconsider format 1 where more than one identifier-2 may be specified.
Maybe add the sentence "Where there is more than one identifier-2, each pairing with identifier-1 shall be treated separately."
Rule 6a, maybe add the sentence "When identifier-2 is both a sending and receiving field, its contents are undefined."
102 Evaluate statement, 14.10.12, table 13, page 442
Intersection of "TRUE or FALSE" on both row and column. I don't think that this should be permitted, see general rules 3a3 and 3a4, also syntax rule 7b.
103 Exit statement, 14.10.13.2, Syntax rules, page 444
Rule 3, this conflicts with 14.2 syntax rule 7, which only allows level 3 EC-USER exceptions to be specified in the raising phrase. Also see 14.10.13.3, general rule 3c1.
104 Inspect statement, 14.10.21.2, Syntax rules, pages 459-460
Rule 5, add the clause ",that has no decimal places and no "P" symbols in its defining picture string".
105 Multiply statement, 14.10.25.2, Syntax rules, page 478
I think that the composite of operands should be determined in the same way as for the add statement (14.10.2.2, syntax rules 1a and 1b).
Also that each pairing of identifier-2 and the common identifier-1 should be treated separately as per my comments on the divide statement.
106 Perform statement, 14.10.27.3, General rules, pages 487-490
Rule 3, re "This transfer of control occurs only once for each execution of a PERFORM statement.". Maybe add the clause ", though the specified set of statements may then be executed repetitively under the direction of the PERFORM statement."
Rule 4, insert ", EXIT" after the words "GO TO".
Rule 4, insert the words "format 1" in front of the pre-existing word "EXIT".
Rules 7 and 8, review of the behaviour of the EXIT SECTION statement could be desirable. For example, consider the case where a section contains para-1, para-2, para-3 and para-4, where para-4 contains the format 1 EXIT statement and para-1 contains the EXIT SECTION statement. Performing para-1 thru para-2 would then lead to the unconditional transfer of control to the end of the section such that para-2 is not entered and therefore control does not return to the end of the invoking PERFORM statement, but instead continues with next statement physically following the end of the section, if any. The GO TO statement could be used similarly with the same effect. I wouldn't personally wish to write programs in this manner, but it is allowed, or at least not specifically prevented. Maybe this topic should be dealt with under 14.7.2 explicit and implicit transfers of control, since the SORT and MERGE input and output procedures would be liable to the same sorts of problem.
Rule 8, would this also apply to a PERFORM being used within a SORT or MERGE procedure to pass through the exit of that SORT or MERGE procedure. See 14.10.36.3 SORT statement, general rules 10 and 13 and 14.10.23.3 MERGE statement, general rule 9.
Rule 8, maybe something similar would be desirable for the case where a PERFORM statement is within its own range, such that it invokes itself. Again 14.7.2 might be a better place to deal with this topic.
107 Read statement, 14.10.29.2, Syntax rules, page 492
Rule 5, for consistency with general rule 14, the NEXT phrase should also be excluded.
108 Resume statement, 14.10.31, Resume statement, page 500
Introduction, replace "a statement" by "the statement".
109 Search statement, 14.10.34.3, General rules, page 505
Rule 5, on the first line, insert "it is the user's responsibility to ensure that" in front of "the following conditions".
110 Set statement, 14.10.35, introduction, page 512
line 6, replace "decreasing the amount of storage allocated for a dynamic table" to "changing the amount of storage allocated for a dynamic table".
Dynamic tables have been removed.
111 Set statement, 14.10.35.3, General rules, page 516-519
Rule 15, shouldn't the last paragraph of rule 16 also be the last paragraph of rule 15, suitably adapted by replacing "SORT" by "MERGE".
This format has been removed in CD1.6
Rule 22, insert "is set to" at the beginning of line 2.
Rule 23, insert "in the TO phrase" after "specified" in line 1.
112 Sort statement, 14.10.36.3, General rules, pages 522-525
Rule 9, as it is not necessary for an input procedure to read an input file, I think it would be desirable to insert the text "create, " in front of the word "select" in the first line.
Rule 12, as it is not necessary for an output procedure to write an output file, I think it would be desirable to insert the text "process, " in front of the word "select" in the first line.
113 String statement, 14.10.39.2, Syntax rules, page 531
Rule 7, I can't see the need for the first sentence, but it might be desirable to replace it with the following.
A DELIMITED phrase is transitive for all preceding instances of identifier-1 or literal-1 until a previous DELIMITED phrase is encountered.
114 String statement, 14.10.39.3, General rules, pages 531-533
Rule 9, see comments on UNSTRING general rule 17b.
115 Subtract statement, 14.10.40.2, Syntax rules, pages 534-535
Rule 1a, replace existing text by "In format 1, by separately pairing the common set of all instances of identifier-1 and literal-1 with each instance of identifer-2.". Also see ADD, DIVIDE and MULTIPLY.
116 Subtract statement, 14.10.40.3, General rules, page 535-536
Rule 1, third main para, third line, replace "the" by "each" to allow for multiple occurrences of identifier-2.
Subtract statement, 14.10.40.3, General rules, page 535-536
Rule 4, replace "insures" by "ensures".
117 Unstring statement, 14.10.44.3, General rules, pages 540-543
Rule 17b, I think that the rule should be split into two components, one for the case where the "ON OVERFLOW" phrase is specified and one for the case where it isn't. This would correspond to the standard's treatment of the CALL statement among others. Alternatively, the text of 14.7.9.2.3 non-fatal exception conditions should be expanded to allow for the possibility of non-returning transfers of control, such are allowed for in rule 18. In the latter case the description of the CALL statement among others could also be suitably revised.
Same applies to rule 9b of the 14.10.39 STRING statement.
The rules for fatal exception conditions 14.7.9.2.2 contain a reference to non-fatal exception conditions in a similar vein.
118 Write statement, 14.10.47.1, Syntax rules, pages 552-553
Rule 11, revise to read "Integer-1 shall be positive or zero.".
119 Write statement, 14.10.47.3, General rules, pages 553-558
Rule 14, shouldn't text about transfer of control, rather like that of rule 25, be included.
Rule 20, replace "the records are in an undefined order" by "the added records all follow the records present in the file when it was opened, but are otherwise in an undefined order".
Rule 27, I don't understand "the logical record is presented".
120 Intrinsic Functions, 15.1, Types of functions, page 559
Item 5, maybe add the clause ,"the implicit use of the "P" picture string symbol is not permitted."
121 Intrinsic Functions, 15.2, Arguments, page 560
Item 5, I tend to think that the use of the "P" picture symbol should be disallowed in the definition of an integer data item. Though maybe a conversion would be allowable, provided that a size error did not happen as a result of such a conversion.
Maybe, after the first sentence, insert the sentence
"Where an integer data item is used as an argument, its picture string shall not contain the "P" symbol.".
Or use the sentence
"Where an integer data item containing "P" symbols in its picture string is used as an argument, it shall be treated as an arithmetic expression, where the integer data item is first converted to the equivalent representation without a "P" symbol, such a conversion can result in a size error.".
122 Intrinsic Functions, 15.3, Returned values, pages 561-562
I think that the very last paragraph should disallow integers with implicit "P" picture string symbols.
123 Intrinsic Functions, 15.4, Date conversion functions, page 562
While I don't disagree with the general treatment in the standard, which I think is very good. I do feel that some more explanations and caveats would be helpful.
1) It is not possible to accurately predict conversions between Gregorian dates and integer days in the very long term future. Nor is it possible to predict conversions between these forms of date and TAI seconds, even in the very much shorter term future, i.e. more than a few months ahead. My notes (99-0217 and still in progress) on dates, times and durations explain this in some detail.
The conversion between Gregorian dates and integer days is probably good for about 2000 years, barring unforeseen events.
It is highly probable that the Gregorian calendar, as currently defined, will apply too many leap days over the next 8000 years and that, consequently, some will have to be dropped.
2) The term Julian date as used in some of the functions is what the draft ISO8601:1997 describes as an ordinal date, which would be a better description. I haven't seen the final version of ISO8601:1999 yet. Astronomers often use the term Julian date to refer to the use of Julian days with associated times, while historically and probably most accurately Julian dates refer to dates of the Julian calendar and were still used by some countries until the early 20th century.
3) A note to the effect that Julian days and modified Julian days can be derived from integer-date by adding or subtracting the appropriate numbers would be desirable.
Julian day for 1st January 1601 starting at midnight is 2,305,447.5 + 365 + 1 = 2,305,813.5, according to my calculations using the tables on page K4 of the 1989 Astronomical Almanac. It should be noted that Julian days start at noon.
A modified Julian day is the Julian day minus 2,400,000.5, it starts at midnight rather than at noon.
4) Maybe add functions to convert Gregorian and integer dates to and from TAI seconds. There would need to be a proviso that conversions for future dates can not be accurately predicted for more than a few months ahead, because of the vagaries in the application of leap seconds. It would also be necessary to consider how backward extrapolation from 1972 should be done, since while TAI, which uses SI seconds, can be extrapolated directly back to 1956, prior to the introduction in 1972 of the redefined UTC, when leap seconds were formally introduced, the previous forms of UTC, UT1 and GMT used the concept of a year containing exactly 86400 seconds, even if some seconds had to be slightly longer or shorter than normal during the period from about 1960 to 1972.
5) Maybe explain the relationship between CORBA's definition of UTC seconds and TAI seconds. I don't know it myself for sure. The base time for CORBA's definition is 15th October 1582 at 00.00 hours, which is when the Gregorian calendar was first adopted by a limited number of Roman Catholic countries. Presumably, until 1972, it uses seconds that were 1/86400th of a calendar day, where those during the earlier forms of UTC from the 1960's were of occasionally variable length within the same year. I don't currently know whether this form of time reckoning was devised specifically for CORBA or whether it was obtained from some other standard.
Both UTC and TAI use the SI second as the measurement of the length of a second. At the time of the introduction of the redefined UTC on the 1st January 1972, the difference between TAI and UTC was set at ten seconds and, by the use of leap seconds, the difference is always maintained as an integral number of seconds.
124 Intrinsic Functions, 15.5 Summary of functions, pages 562-566
Table 20:
DAY-OF-INTEGER - uses term "Julian date" inappropriately
INTEGER-OF-DAY - uses term "Julian date" inappropriately
LOCALE-DATE - replace "data" by "date"
TEST-DAY-YYYYDDD - uses term "Julian date" inappropriately
Why is a function, which has only alphabetic arguments, of type alphanumeric? (see LOWER-CASE, MAX, MIN, REVERSE, UPPER-CASE,...)
125 Intrinsic Functions, 15.16, CURRENT-DATE, page 577
The range of seconds allowable in character positions 13-14 should be 00-60 to accomodate leap seconds. Don Schricker has already mentioned this to me.
For the character position 17, in the fourth line, replace "GCoordinated Universale" by "Coordinated Universal Time".
126 Intrinsic Functions, 15.17, DATE-OF-INTEGER, page 578
see 15.4 Date conversion functions
127 Intrinsic Functions, 15.19, DAY-OF-INTEGER, page 580
see 15.4 Date conversion functions
128 Intrinsic Functions, 15.18, DAY-TO-YYYYMMDD, page 579
15.18.2, Arguments, item 1
I think that this could reasonably exclude the value zero. Perhaps the rule should be restated as "Argument-1 shall be a non-zero positive integer less than 1000000.". I know that validation can be done with TEST-DAY-YYYYMMDD, but following that line, negative values could also be allowed.
129 Intrinsic Functions, 15.20, DAY-TO-YYYYDDD, page 581
15.20.2, Arguments, item 1
I think that this could reasonably exclude the value zero. Perhaps the rule should be restated as "Argument-1 shall be a non-zero positive integer less than 100000.". I know that validation can be done with TEST-DAY-YYYYDDD, but following that line, negative values could also be allowed.
130 Intrinsic Functions, 15.26, EXCEPTION-STATUS, page 587
Perhaps EXCEPTION-NAME would be a more suitable name.
131 Intrinsic Functions, 15.31, HIGHEST-ALGEBRAIC, page 592
15.31.2 Arguments - replace "Arguments-1" by "Argument-1".
132 Intrinsic Functions, 15.35, INTEGER-OF-DAY, page 596
see 15.4 Date conversion functions
133 Intrinsic Functions, 15.53, NUMVAL-C, page 614
15.53.2 Arguments, item 2, second line, replace "shalll" by "shall".
134 Intrinsic Functions, 15.78, WHEN-COMPILED, page 640
The range of seconds allowable in character positions 13-14 should be 00-60 to accomodate leap seconds. Don Schricker has already mentioned this to me.
135 Communications Facility, Annex A.1.2.2, Syntax rules, pages 647-648
Rule 14, last word of paragraph, split into "rule" and "24".
136 Communications Facility, A.2.1, ACCEPT statement, page 657
A.2.1.3 General rule 2, last line, separate "See" from "A.1.2".
137 Communications Facility, A.2.5, RECEIVE statement, page 661
A.2.5.3 General rule 1, last line, separate "See" from "A.1.2".
A.2.5.3 General rule 1, second line, separate "See" from "A.1.2".
138 B.1, Implementor-defined language element list, page 667
General, the phrase "conditioned upon" is often used in place of "conditional upon".
Item 8, Alphanumeric literals, first line, insert the word "are" before "permitted".
Item 80, Floating-point numeric literals, replace "minumum permittedvalue" by "minimum permitted value".
Item 160, RETRY phrase, first line, separate "shall" from "be".
Item 172, SET statement default locale, general rules "2122" and "2123" are incorrectly specified. Probably should refer to general rules 22 and 23.
139 B.2, Undefined language element list, page 682
Item 4, Cancel statement, for the benefit of portability, I would rather that the behaviour in such circumstances were defined. Either the CANCEL statement should set any associated program pointers to null, so that the EC-PROGRAM-PTR-NULL exception would be raised in such cases, or such pointers should always remain valid.
Item 28, Merge statement, insert "file format" in front of "SORT".
Item 44, Search statement, line 2, separate "index" from "14.10.34".
140 Files, C.1, page 690
Maybe a reference should be made to 9.1 Files, which already covers some of this ground. Perhaps introductory references to other relevant portions of the standard would also be helpful, while the input-output statements are reasonably obvious items for a newcomer to look up, the details of the Input-output section and File section could be pointed out.
Similar comments could be made about several other concept entries.
141 Files, C.1.2.1.1, Sequential access mode, page 692
Perhaps add the following as a final paragraph:
For all file organizations and provided that the input-output device supports the feature, records may also be read sequentially, using the PREVIOUS phrase with the READ statement, in the exact reverse of the order in which they are organized within the file.
142 Files, C.1.2.2.1, Sorting and Merging, page 693
I think the following (or similar) should be included under this heading:
"Sorts and Merges are used to organize records from one or more files into a sequence based upon specified keys that are data items within those records.
Sorts are used to order records from files that were not originally in the required sequence, while merges are used to combine records from two or more files within each of which the records were already in the required sequence.
Programs (Maybe "run unit" would be a more accurate term? The SORT and MERGE statements don't specify this explicitly, maybe it is implementor defined. "COBOL run unit" could be an even better term, thereby allowing implementors to decide whether these rules apply to non-COBOL components.) may contain several sorts and merges, though only one may be active at any one time, with the exception of table sorts of which any number may be active at once and at the same time as a file sort or merge."
143 Files, C.1.2.3.4, Optional phrases, page 694
Mention could be made of the NOT AT END and NOT INVALID KEY phrases, together with the fact that the AT END and INVALID key phrases are mutually exclusive within an input-output statement, as also are the NOT AT END and NOT INVALID KEY phrases.
Maybe this should be done in the following way:
Insert a new paragraph after the first:
"The NOT INVALID KEY phrase can be specified in the same statements that the INVALID KEY phrase can be specified in and they can be specified together in the same statement, though not necessarily. If the input-operation completes successfully and the invalid key condition is not true, then the statement identified by the NOT INVALID KEY phrase is executed."
Insert a new paragraph after the existing second:
"The NOT AT END KEY phrase can be specified in the same statements that the AT END phrase can be specified in and they can be specified together in the same statement, though not necessarily. If the input-operation completes successfully and the at end condition is not true, then the statement identified by the NOT AT END phrase is executed."
I have used the same formulation for the not at end condition as the not invalid key condition, because although NOT AT END can only be specified in a READ statement, there may be more than one READ statement within a program.
144 Files, C.1.3.1, File sharing, page 695
First sentence, there is a conflict with table 17 in the description of the OPEN statement, which allows file sharing when a file is already open in the OUTPUT mode.
145 Files, C.1.3.2.1, Automatic locking, page 696
The last sentence of the first paragraph looks mangled. Perhaps the word "file" should be added after the word "physical". Or replace "physical" by "same physical file".
The last paragraph refers to table C.nn, which should be resolved to table C.1.
146 Files, C.1.3.2.2, Manual locking, page 697
First paragraph, last sentence, replace "is a matter of" by "requires".
The last paragraph refers to table C.nn, which should be resolved to table C.1.
147 Files, C.1.3.2.2, Table C.1, page 698
READ with lock mode automatic multiple, fourth column, replace "specifiede" by "specified".
START third column, replace "nno" by "no".
148 Files, C.1.3.3, RETRY, page 699
Maybe add the phrase ", by setting the File Status data item and raising an exception condition." to the final sentence.
149 Tables, C.2.1, Table definition, page 700
In the paragraph commencing with "In example 2..." maybe replace "does not since" by "defines a two-dimensional table, because".
150 Tables, C.2.3, References to table items, page 701
After the first sentence, insert a new sentence, "Intrinsic functions can also be exceptions, depending on the rules for the individual function.".
151 Tables, C.2.4.3, Search example, page 704
First para, revise "representative" to "representation".
To the right of the first box on the left, add the word "exceeds" before "highest" and add the word "true" above the line in front of "AT END" and maybe with "AT END" in parentheses. Both "AT END" and the box to its right should be marked with an asterisk. Perhaps position "AT END" above that box.
In the top left box replace "occurence" by "occurrence".
Replace the less than or equal sign under the top left box with the word "false".
I think that the three occurrences of the "imperative-statement-1" to the right of the main sequence should instead be consecutively numbered from 1 to 3.
A caveat about the effect of the index setting being less than one might be helpful.
152 Tables, C.2.5.1, Example 1, page 705
First para, second line, replace "determine" by "specify". While "determine" can be used in this way, most people would probably think that what was meant was to find out which way the table was already sequenced rather than how the sort process was going to do the sequencing.
153 Tables, C.2.5.3, Example 3, page 705
First para, first line, insert the word "a" before the word "sort".
154 Compilation group... , C.4.1.2, Runtime level organization, page 711
Third para, second sentence, I am not sure whether this means what it says. If parameters from the operating system are allowable then it should say so explicitly.
155 Compilation group... , C.4.5.1.1.1, Names of Programs, page 717
It would be safer to insist that all program names in a run unit must be unique. While the rules of C.4.5.1.1.3 would (probably) work, they could easily be misinterpreted by a programmer. I'm not sure what would or should happen if the contained program DUPLICATE-NAME were recursive. Perhaps there could be a mechanism for qualifying program names in the same way as for data names, or even a way of specifying CALL statements to indicate whether a contained program was intended to be called.
Second para, first line, separate the words in "theoutermost".
156 Compilation group... , C.4.5.2.2, Argument passing mechanisms, pages 719-720
Fourth para, last sentence, perhaps add "in the activating runtime element" after "argument" to make the meaning clearer.
157 Compilation group... , C.4.5.2.5, Prototypes, pages 720-721
Second para, second line, revise "used. Functions" to "used. Function", also note the additional space between the two words.
158 Compilation group... , C.4.5.3, Sharing data, pages 721-722
Item 3, last line, rephrase "may refer to a data item" to "may then refer to that data item".
159 Intrinsic function facility, C.6, page 730
Text para 6, commencing "Some functions...", second line, replace "GMT" by "UTC".
160 Debugging, C.7, page 732
Maybe a statement such as that in the second paragraph of C.5 Communication facility should be included to indicate that this is an obsolete, or more accurately an obsolescent, feature.
161 Source text manipulation facility, C.8, page 733
Perhaps replace the last paragraph with the following:
"With the exception of the COPY and REPLACE statements, original library and source text need not be syntactically correct COBOL source code. The compiler checks the syntax of the source code after the application of the COPY and REPLACE statements and the other conditional compilation facilities."
162 Addresses and Pointers, C.10, page 736-737
Page 736, first para, second line, replace "application" by "applications".
Page 737, fifth text grouping from the top, put "SAM JONES" in quotes or apostrophes.
163 Boolean support and bit manipulation, C.11, pages 738-740
Page 740, last para, this would mean that neither example of a-group could be used as an argument in a CALL statement. Perhaps add the sentence:
"When a group item is passed, the first elementary data item contained within it must begin on a byte boundary.".
This would also cover situations where there were preceding usage national data items within the group being passed.
164 Culturally specific ..., C.14.2.3, Locale-based collating sequences, page 751
Second para, replace first word "TThis" by "This".
165 Standard Arithmetic, C.17.1.1.1, ADD and SUBTRACT statements, page 757
An explanation of the term composite of operands or a reference to 14.8.4 Arithemetic statements would be desirable here.
166 Object ..., C.18.2.3, Object references, page 764
Second para, line six, split "inC.18.4.4".
167 Object ..., C.18.10.1, Main program, page 775
Is the spelling of the method "displayUI" intentional? Also in 18.10.2.
168 Object ..., C.18.10.2, Account class, page 777
The overprinting of another page on this page looks like a typo.
169 Report Writer, C.19, generally, pages 778-784
The code examples would be better for using free-form reference format style comment indicators. Their alignment is then irrelevant.
170 Report Writer, C.19.2.1, PAGE, page 779
The details of item 2 seem to be missing.
171 Report Writer, C.19.6, Totalling, pages 783-784
I am not clear how SUM OF RS-PAY can be used as four separate items at once under "TYPE CF FOR WS-MONTH".
172 Report Writer, C.19.7, Procedure division statements, page 784
I think that the readability of the first paragraph could be improved. At least remove the two phrases "in order of execution" on lines 4 and 7.
The example might be improved by using PERFORM with TEST AFTER and consolidating the obtaining of input data before the two GENERATEs within the PERFORM.
173 Validate, C.20, generally, page 785-788
The code examples would be better for using free-form reference format style comment indicators. Their alignment is then irrelevant.
174 Validate, C.20.1, General description, page 785
First para, first line, "ddefined" is a typo.
First para, third line, replace "issued" by "issued or set".
Second para, third line, insert a comma before "but".
175 Validate, C.20.3, Input distribution, page 785
Perhaps add VARYING to the list of clauses.
176 Validate, C.20.4, Content validation, page 785
Perhaps add VARYING to the list of clauses.
177 Validate, C.20.5, Relation validation, page 785
Perhaps add VARYING to the list of clauses.
178 Validate, C.20.8, Example of validation, page 786
I think that although "ALLOW ONLY SPACES WHEN IN-TYPE > 3" is syntactically correct and acceptable in this position, because of the previous "PRESENT WHEN" phrase, it would never be activated. Maybe the PRESENT WHEN condition could be revised in some way as to make this allowable, perhaps by permitting IN-TYPE to be also be zero and revising the ALLOW phrase to use a "< 1" condition.
The term "ascending" could be used instead of "non-descending".
179 Inspect, C.22, title, page 793
More concise titles would be "INSPECT examples", "INSPECT statement examples" or "INSPECT facility".
180 Inspect, C.22, Example 3, page 794
Expand the first column of the table to allow all characters for an item to be shown on one line.
181 Perform, C.23, title, page 796
More concise titles would be "PERFORM examples", "PERFORM statement examples" or "PERFORM facility".
182 Perform, C.23, first paragraph, page 796
Several of the references are run onto the preceding words or punctuation marks without an intervening space.
183 Free-form reference format, C.24, page 800
The first source directive should commence with two contiguous ">" symbols according to Compiler directives, 7.2.2, syntax rule 5.
184 Annex D.1, generally, page 802
Would it be possible to arrange items alphabetically, or at least those relating to specific features as is done in D.2.
185 Annex D.1, item 26, Incompatible data, page 810
Why isn't a move to an alphabetic data item subject to the same condition when the contents would be invalid. see MOVE general rules 4c and table 15, Validity of types of MOVE statements and 14.7.9.1, Incompatible data? Is this intentional?
186 Annex D.2, item 93, PICTURE clause omission, page 820
Does this include alphabetic literals, or is the term subsumed within alphanumeric literals.
187 Annex D.2, item 97, PICTURE clause "E" symbol, page 820
This does potentially affect existing programs, see D.1 item 10.
188 Annex D.2, item 98, PICTURE clause "N" symbol, page 820
This does potentially affect existing programs, see D.1 item 9.
189 Annex D.2, item 112, Report Writer, page 821
On the line starting, "COLUMN, LINE,", "once" is a typo for "one".
190 Annex D.2, item 130, Subscripting with arithmetic expressions, page 822
Maybe revise "Any arithmetic expression" to "Any arithmetic expression resulting in an integer".
191 Annex D.2, item 138, Validate facility, page 823
Perhaps append "or GENERATE", ", INITIATE, GENERATE or TERMINATE" or "the report writer statements" to the final word, or some suitable variant.
192 Annex D.2, item 142, VARYING clause facility, page 823
Add that "It can also be specified in a data description for use in conjunction with the VALIDATE facility."
193 Annex E.1, Move of alphanumeric figurative constants to numeric items, page 824
Perhaps add "The use of the new intrinsic functions "HIGHEST-ALGEBRAIC and "LOWEST-ALGEBRAIC" permits the programmer to easily set the contents of a numeric data item to its highest or lowest possible valid value respectively, without the error-prone task of using possibly very long numeric literals to do so. The use of these functions also makes the task of revising the length of data items in program amendments simpler and less error prone.".
194 Annex E.2, Debugging lines and the DEBUGGING MODE phrase, page 826
I would be sorry to see this feature made obsolete, I have used it quite a lot for batch programs and find it easy to use. Although, improved debugging tools make the task of debugging easier, I find that rather than have to step through all or a lot of the code, some judicious debugging lines with DISPLAY statements and attached conditions to restrict volume can make it easier to see what has been done.
Admittedly, most of the debugging tools that I have used have been less than perfect and often run away and skip break points, one could reasonably expect them to improve with time. The use of a trace of procedure names coordinated with data item displays makes it easier to review what has been done, allowing one to backtrack to earlier events to recheck certain details. It can be very frustrating to use a debugging tool and find that one has missed some earlier event that was relevant and have to start the session again. One might not even know which earlier event was relevant until some time after it had executed. By having debugging output in a file, one can search for and review details of execution of particular aspects at leisure, while having been selective about the volume of that output, to keep it to a reasonable and manageable level.
I would like to be able to use debugging tools, debugging lines and conditional compilation according to circumstances, separately or in combination. The use of conditional compilation as a replacement for debugging lines seems to require the addition of a lot of extra text to achieve the same effect.
The use of debugging lines could perhaps be improved by removing the current ambiguities in respect to the COPY and REPLACE statements and by replacing the "SOURCE-COMPUTER. WITH DEBUGGING MODE" paragraph by an equivalent compiler directive, which to be valid (or effective for a program) would have to precede or immediately follow the IDENTIFICATION DIVISION header, which would have to be present. The presence or absence of such a compiler directive could then be checked by the conditional compilation features IF and EVALUATE, e.g. "IF DEBUGGING DEFINED". The use of a directive could simplify the application of the feature for nested programs about which I have to think some more.
Such a directive might take the forms ">>DEBUGGING ON/OFF [WITH/WITHOUT TRACE]". A new form of SET statement also could be used, e.g. "SET DEBUGGING ON/OFF [WITH/WITHOUT TRACE]", such statements would have to be on debugging lines and would therefore be ignored by the compiler when the ">>DEBUGGING ON" directive was not in effect.
Non-procedure division debugging lines would be compiled when the ">>DEBUGGING ON" directive was active, Procedure division debugging lines would be compiled when the "DEBUGGING" directive was active, but would only be executed when not countermanded by a "SET DEBUGGING OFF" statement. They could be reactivated by a "SET DEBUGGING ON" statement and both statements could be executed many times within a program, depending on the flow of control. Where, during the course of execution, a "SET DEBUGGING ON/OFF" statement repeats an earlier such statement that is still in effect, it would be ignored, except where it changes the status of the TRACE feature.
IBM supplied "READY TRACE" and "RESET TRACE" facilities in earlier versions of COBOL. "READY TRACE" simply provided a list of the procedure names through which control passed during execution, while "RESET TRACE" turned this feature off. Both statements could be used multiple times within the same program, could be subject to conditional statements and operate similarly to other statements in the course of execution, rather than just by position in source code in the manner of directives. While their output could be voluminous, they could also be very useful and judicious control could be used to limit the volume of output. DISPLAY statements could be used in conjunction with READY TRACE to show the content of data items in the same listing as the trace, positioned as they were issued.
However, at this late stage of the development of the current draft standard, such alterations would probably best be left to the next version of the standard.
195 Annex F, Debugging line interactions with the SOURCE-COMPUTER paragraph, page 827
Also see comments re Annex E.2.
Perhaps the difficulties with the COPY and REPLACE statements could be resolved by ensuring that for a single COPY or REPLACE statement, it is either all on debugging lines or none of it is on a debugging line. I don't think that it would be much effort for a programmer to code separate statements with and without the features required for use with debugging lines in conjunction with conditional compilation. Often, one would only want the COPY or REPLACE statement when in debugging mode, when control would be easy. I must admit to not having used debugging lines with the COPY and REPLACE statements, nor even to have used the REPLACE statement at all. However, I can see that such a use might be convenient at times.
I don't think that the presence or absence of a SOURCE-COMPUTER paragraph is a serious problem, when it is absent debugging lines are treated as comments, unless a containing program contains such a paragraph with the DEBUGGING MODE phrase. Its replacement with a compiler directive of equivalent meaning might remove this perceived difficulty as such a directive would have effect until turned off again. Use of a directive could provide more versatility and reduce the number of statements required for nested programs.